<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Creating Your Application</title>
<link href="../style.css" rel="stylesheet" type="text/css">
</head>
<BODY>
<div class="header">
<h1>QuickFIX/J User Manual</h1>
</div>

<H2>Creating Your QuickFIX/J Application</H2>
<p> Creating a FIX application is as easy as implementing the QuickFIX Application
  interface.</p>
<code>
<pre>package quickfix;

public interface Application {
  void onCreate(SessionID sessionId);
  void onLogon(SessionID sessionId);
  void onLogout(SessionID sessionId);
  void toAdmin(Message message, SessionID sessionId);
  void toApp(Message message, SessionID sessionId)
    throws DoNotSend;
  void fromAdmin(Message message, SessionID sessionId)
    throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, RejectLogon;
  void fromApp(Message message, SessionID sessionId)
    throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType;
}
</pre>
</code>
<p> By implementing these interface methods in your derived class, you are requesting
  to be notified of events that occur on the FIX engine. The function you that
  you should be most aware of is <I>fromApp</I>.</p>
  <p>
  Here are explanations of what these functions provide for you.</p>

<dl>
<dt>onCreate</dt>
<dd>This method is called when quickfix creates a new session. A session
  comes into and remains in existence for the life of the application. Sessions
  exist whether or not a counter party is connected to it. As soon as a session
  is created, you can begin sending messages to it. If no one is logged on, the
  messages will be sent at the time a connection is established with the counterparty.</dd>
  <dt>onLogon</dt>
  <dd> This callback notifies you when a valid logon has been established
  with a counter party. This is called when a connection has been established
  and the FIX logon process has completed with both parties exchanging valid
  logon messages. </dd>
  <dt>onLogout</dt>
  <dd> This callback notifies you when an FIX session is no longer online.
  This could happen during a normal logout exchange or because of a forced termination
  or a loss of network connection. </dd>
  <dt>toAdmin</dt>
  <dd> This callback provides you with a peek at the administrative messages
  that are being sent from your FIX engine to the counter party. This is normally
  not useful for an application however it is provided for any logging you may
  wish to do. Notice that the FIX::Message is not const. This allows you to add
  fields to an administrative message before it is sent out. </dd>
  <dt>toApp</dt>
  <dd> This is a callback for application messages that you are being
  sent to a counterparty. If you throw a <I>DoNotSend</I> exception in this function,
  the application will not send the message. This is mostly useful if the application
  has been asked to resend a message such as an order that is no longer relevant
  for the current market. Messages that are being resent are marked with the <I>PossDupFlag</I> in
  the header set to true; If a <I>DoNotSend</I> exception is thrown and the flag
  is set to true, a sequence reset will be sent in place of the message. If it
  is set to false, the message will simply not be sent. Notice that the FIX::Message
  is not const. This allows you to add fields before an application message before
  it is sent out. </dd>
  <dt>fromAdmin</dt>
  <dd> This callback notifies you when an administrative message is sent
  from a counterparty to your FIX engine. This can be usefull for doing extra
  validation on logon messages such as for checking passwords. Throwing a <I>RejectLogon</I> exception
  will disconnect the counterparty. </dd>
  <dt>fromApp</dt>
  <dd> This is one of the core entry points for your FIX application.
  Every application level request will come through here. If, for example, your
  application is a sell-side OMS, this is where you will get your new order requests.
  If you were a buy side, you would get your execution reports here. If a <I>FieldNotFound</I> exception
  is thrown, the counterparty will receive a reject indicating a conditionally
  required field is missing. The Message class will throw this exception when
  trying to retrieve a missing field, so you will rarely need the throw this
  explicitly. You can also throw an <I>UnsupportedMessageType</I> exception.
  This will result in the counterparty getting a reject informing them your application
  cannot process those types of messages. An <I>IncorrectTagValue</I> can also
  be thrown if a field contains a value that is out of range or you do not support.
</dl>
<p> The sample code below shows how you might start up a FIX acceptor which listens
  on a socket. If you wanted an initiator, you would simply replace the acceptor
  in this code fragment with a <i>SocketInitiator</i>. <i>ThreadedSocketInitiator</i> and <i>ThreadedSocketAcceptor</i> classes
  are also available. These will supply a thread to each session that is created.
  If you use these you must make sure your application is thread safe.</p>

<pre class="code">
import quickfix.*;
import java.io.FileInputStream;

public class MyClass {

  public static void main(String args[]) throws Exception {
    if (args.length != 1) return;
    String fileName = args[0];

    // FooApplication is your class that implements the Application interface
    Application application = new FooApplication();

    SessionSettings settings = new SessionSettings(new FileInputStream(fileName));
    MessageStoreFactory storeFactory = new FileStoreFactory(settings);
    LogFactory logFactory = new FileLogFactory(settings);
    MessageFactory messageFactory = new DefaultMessageFactory();
    Acceptor acceptor = new SocketAcceptor
      (application, storeFactory, settings, logFactory, messageFactory);
    acceptor.start();
    // while(condition == true) { do something; }
    acceptor.stop();
  }
}
</pre>

<div class="footer">More information at <a href="http://www.quickfixj.org/">www.quickfixj.org</a></div>

</BODY>
</html>
